Would it make more sense for the sympyprinting extension to live as part of SymPy, so it could easily be kept in sync with changes like this?

To explain more: any importable module with a load_ipython_extension function can be used as an extension, so it could live as e.g. sympy.printing. Extension docs are here: http://ipython.org/ipython-doc/stable/config/extensions/index.html#writing-extensions

I think that is a good idea. How should we go about doing this. Will having the extension living both in sympy and ipython for backwards compatibility with sympy 0.7.1 result in issues? i.e. is there any good way to ensure that the most resent version is loaded?

I guess we'd do something like this:

• Copy this module into Sympy as sympy.printing (or whatever it makes sense to call it). Make whatever changes to work with current Sympy.
• Within the version remaining in IPython, load_ipython_extension() should try to import sympy.printing - if that succeeds, it will print a "deprecated" message pointing to the new name and call that module's load_ipython_extension(). If it fails, it falls back to the code in this module (i.e. assuming that SymPy is an older version).
• Once we think everyone's using the new version, we can delete the copy within IPython.

Also, while we're working on it, it would be good to remove the global _loaded flag - we're trying to move away from the idea that there's only one IPython shell in a given process. It could set an attribute on the shell instead, like ip._sympy_extension_loaded.

Just tried out removing the global loaded flag. This seems to work. If this is the way we want to go I will prepare a pull request against sympy for this version and see what they think.

I think putting it in sympy makes sense, although maybe others would disagree.

About the loaded flag - on reflection, is there any harm in simply running the loading code again if the user re-runs %load_ext? Alternatively, maybe the 'load only once' logic should be in the extension manager. I'll ask on the dev list for other opinions.

For this extension there seems to be no problem reloading the extension, but it may be different for others. All the
extensions that ship with ipython seems to use the global _loaded flag.

They do for now, but I want to change that. I don't know if you're
subscribed to the dev list - I've just posted about it here:
http://mail.scipy.org/pipermail/ipython-dev/2012-September/010354.html

Thanks,
Thomas

I am +1 on moving the sympy printing extension to sympy. The global flag is only need to prevent adverse affects from reloading the extension. If there isn't a problem we reloading, the flag is not needed.

See #2462 for getting rid of the global flag (but I haven't touched sympyprinting in that).

I'm not sure if you get a GitHub notification from cross referencing a pull request, but as a note for those interested, I've opened sympy/sympy#1556 to move the sympyprinting extension to SymPy.

This was also discussed at #1523.

Just a small update. Sympy now has a printing extension with this problem solved in sympy.interactive.ipythonprinting
thanks to the work of @flacjacket so we don't need to do any thing here for 0.13.1 but we should provide a fallback to the sympy extension in ipython for 0.14

Do you guys want to start a deprecation cycle for the sympy printing extension in 0.13.1? We should have the SymPy 0.7.2 final out this weekend, unless a serious blocker comes up. When would the release date for 0.13.1 be?

See #2480

Since #2480 is now doing this we can close this one